home *** CD-ROM | disk | FTP | other *** search
/ Hackers Handbook - Millenium Edition / Hackers Handbook.iso / library / hack99 / dll_advisory.txt < prev    next >
Encoding:
Text File  |  1999-03-24  |  9.7 KB  |  237 lines
  1.                           L0pht Security Advisory
  2.  
  3.    
  4.            Release date: February 18, 1999
  5.             Application: Microsoft Windows NT 4.0
  6.                Severity: any local user can gain administator privileges
  7.                          and/or take full control over the system
  8.               
  9.                  Author: dildog@l0pht.com
  10.                     URL: http://www.L0pht.com/advisories.html
  11.  
  12. ---
  13. Overview :
  14. ---
  15.  
  16.     Microsoft Windows NT 4.0 implements a system-wide cache of
  17. file-mapping objects for the purpose of loading system dynamic link
  18. libraries (DLLs) as quickly as possible. These cache objects, located in
  19. the system's internal object namespace, are created with permissions such
  20. that the 'Everyone' group has full control over them. Hence, it is
  21. possible to delete these cache objects and replace them with others that
  22. point to different DLLs. 
  23.  
  24.     When processes are created, the loader maps/loads the loading
  25. executable's imported DLLs into the process space. If there is a DLL cache
  26. object available, it is simply mapped into the process space, rather than
  27. going to the disk. Hence, there is an exploitable condition, when a
  28. low-privilege user replaces a DLL in the cache with a trojan DLL, followed
  29. by a high-privelege account launching a process. The high priveleged
  30. process will map in the trojan DLL and execute code on behalf of the low
  31. privelege use r. 
  32.  
  33. --- 
  34. Affected systems:
  35. ---
  36.  
  37.     Windows NT 4.0 Server SP4
  38.     Windows NT 4.0 Workstation SP4
  39.         Other service packs are likely to be vulnerable, but the exploit has
  40.         not been tested on them, neither has the fix presented below.
  41.  
  42. ---
  43. Description :
  44. ---
  45.  
  46.     The Windows NT object namespace is the place where the kernel
  47. keeps the names of mutexes, semaphores, filemapping objects, and other
  48. kernel objects. It is organized hierarchically, like a directory
  49. structure. Amongst the directories are: 
  50.     
  51.     \Device
  52.     \BaseNamedObjects
  53.     \Driver
  54.     \KnownDlls
  55.     ...
  56.     
  57.     The NT object namespace is browsable with a tool called 'WinObj
  58. 2.0' from System Internals (their website is http://www.sysinternals.com).
  59. You may wish to look around this namespace and browse the default
  60. permissions of objects. It is quiet entertaining, really.
  61.  
  62.     The "\Knowndlls" directory contains a list of DLLs in the
  63. c:\winnt\system32 directory, like: 
  64.  
  65.     \KnownDlls\COMCTL32.dll
  66.     \KnownDlls\MPR.dll
  67.     \KnownDlls\advapi32.dll
  68.     \KnownDlls\kernel32.dll
  69.     ..
  70.  
  71.     All of these objects are created at boot time, and are 'permanent
  72. shared objects'. Normally, users can not create permanent shared objects
  73. (it's an advanced user right, and it is normally not assigned to any
  74. group, even Administrators). But the system pr eloads this cache for you.
  75. Permanent shared objects differ from regular shared objects only in the
  76. fact that they have a flag set, and an incremented reference count, such
  77. that if you create one, and then terminate the creating process or close
  78. all handle s to the object, it does not disappear from the object space. 
  79.  
  80.     To exploit the poor permissions on this cache, one first needs to
  81. delete one of the shared objects by name, in order to later replace it. So
  82. we make a call to the NTDLL.DLL native function "OpenSection()", getting a
  83. handle to the object. Then we call the
  84.  
  85.  NTOSKRNL.EXE native function "ZwMakeTemporaryObject()" which removes the
  86. 'permanent' flag and decrements the reference counter from the object. Now
  87. we just call NTDLL.DLL:NtClose() on the handle and it is destroyed. 
  88.  
  89.     To create a section, one calls NTDLL.DLL:CreateSection(), which is
  90. undocumented. There are other calls one needs to make in order to set up
  91. the object and open the KnownDlls directory, but they are trivial and will
  92. not be discussed here. Feel free to bro wse the source code presented at
  93. the end of this advisory to see what you need to do though. Anyway, you
  94. create a section (aka file-mapping) object that points to a trojan DLL. A
  95. good candidate for DLL trojan is KERNEL32.DLL, since it is loaded by
  96. pretty much every executable you're going to run.
  97.  
  98.     Note that any DLL cache objects you create as a user can not be
  99. 'permanent', hence, when you log out, the cache object _will_ disappear.
  100. So how can we get a higher privelege process to run while we're logged in?
  101. There are many ways. We can wait for an 'A t' job to go off, or we can set
  102. up the DLL hack as an 'At' job that goes off when someone else is logged
  103. in. But more reliable is this: 
  104.     
  105.     When a new Windows NT subsystem is started, it creates a subsystem
  106. process to handle various system details. Examples of these processes are
  107. LSASS.EXE and PSXSS.EXE. The PSXSS.EXE is the POSIX subsystem. But since
  108. no one ever really uses the POSIX subsys tem under NT. So, chances are, it
  109. won't be loaded into memory yet. Once it is, though, it's loaded until the
  110. machine reboots. If it loaded, reboot the machine, and it won't be :P. 
  111.  
  112.     So, we launch our DLL cache hack, and then run a POSIX subsystem
  113. command, thus launching PSXSS.EXE (which runs as 'NT AUTHORITY\SYSTEM',
  114. the system account), and running our DLL with local administrator
  115. privileges. Incidentally, other subsystems have the
  116.  
  117.  same effect, such as the OS/2 subsystem (the only other one that probably
  118. isn't started yet). 
  119.  
  120. --- 
  121. Workarounds/Fixes:
  122. ---
  123.     
  124.     I developed a patch for this security problem in the form of a
  125. Win32 Service program that can be installed by the Administrator of the
  126. system. It sets itself to run every time the system is started, and before
  127. the user has the opportunity to start a program, it adjusts the
  128. permissions of the DLL cache to something much safer. The source code for
  129. t his service is also provided, along with a compiled version. Links to
  130. the programs can be found at http://www.l0pht.com/advisories.html. 
  131.  
  132.     One can verify the validity of the patch by downloading the WinObj
  133. v2.0 tool from System Internals (www.sysinternals.com) and inspecting the
  134. permissions of the KnownDlls directory, and the section objects within it. 
  135.  
  136.     Microsoft has been sent a copy of this advisory, and I would
  137. expect a hotfix from them at some point in the near future. 
  138.  
  139. ---
  140. Example :
  141. ---
  142.  
  143.     I wrote up a trojan to test exploitability, and it was a simple
  144. 'forwarder' DLL that had the same exported names as KERNEL32.DLL, but a
  145. different 'DllMain()' function, to be called when the DLL is loaded. The
  146. function calls in my trojan, simply forward o ff to the real KERNEL32.DLL
  147. calls located in a copy of the kernel that you make in 'REALKERN.DLL' in
  148. the c:\temp directory. 
  149.  
  150.     To try out this vulnerability, obtain an account as a
  151. low-privilege guest user (referred to as 'Dick') and do the following: 
  152.  
  153.     1. Log in as Dick at the console.
  154.     2. Start up two "cmd.exe" shells. Do the following in one of them.
  155.     3. Copy c:\winnt\system32\kernel32.dll to c:\temp\realkern.dll
  156. (The egg dll is hard coded to use the c:\temp directory to find this file.
  157. If you can't put it in c:\temp, then modify the source '.def' file to
  158. point to a different location and recompile eggdll.dll)
  159.     4. Copy the provided hackdll.exe and eggdll.dll to c:\temp
  160.     5. Ensure that there is no file named c:\lockout. If there is,
  161. delete it. The exploit uses this file as a lockfile. 
  162.     5. Delete the KERNEL32.DLL file-mapping object from the system cache:
  163.            c:\> cd\temp
  164.            c:\temp> hackdll -d kernel32.dll
  165.     6. Insert the new file-mapping object with:
  166.            c:\temp> hackdll -a kernel32.dll c:\temp\eggdll.dll
  167.            Don't hit a key in this window after hitting enter.
  168.     7. Now move to the other cmd.exe window that you started.
  169.     8. Run a POSIX subsystem command. A good way to start it is:
  170.        c:\temp> posix /c calc
  171.        (if you have calculator installed. If not, pick some other program)
  172.     9. Now the EGGDLL.DLL will prompt you with a few message boxes:
  173.            Say no to the "User is DOMAIN\DICK, Spawn Shell?" box.
  174.        Say no to the "User is \[garbage], Spawn Shell?" box.
  175.            Say YES to the "User is NT AUTHORITY\SYSTEM, Spawn Shell?" box.
  176.         Say YES to the "Winsta0" window station message box.
  177.            Say YES to the "Desktop" window desktop message box.
  178.        You will now see a "System Console" command.com shell open up.
  179.            (saying yes to the next 'winlogon' box will give you something
  180.             funny when you log out, btw :P)
  181.     10. Now go back to your first cmd.exe window and hit a key to
  182.             unpoison the DLL cache.
  183.     11. In the System Console window, run the User Manager program,
  184.             and modify Dick's account
  185.             (or anyone else's for that matter) to your hearts content.
  186.             (NT Server) c:\winnt\system32> usrmgr
  187.             (NT Workstation) c:\winnt\system32> musrmgr
  188.  
  189. ---
  190. Source and Compiled Code:
  191. ---
  192.  
  193.     Exploit code can be downloaded from L0pht's website at
  194. http://www.l0pht.com/advisories.html. It is available in compiled form,
  195. and in pure source form as two zipfiles. The L0pht patch for this advisory
  196. is also available in both source form and compiled f orm from the same
  197. URL. 
  198.  
  199.  
  200. dildog@l0pht.com
  201. ---------------
  202. For more L0pht (that's L - zero - P - H - T) advisories check out:
  203. http://www.l0pht.com/advisories.html
  204. ---------------
  205.  
  206. ----------------------------------------------------------------------------
  207.  
  208. Date: Fri, 19 Feb 1999 11:23:44 +0000
  209. From: Paul Ashton <paul@ARGO.DEMON.CO.UK>
  210. To: BUGTRAQ@netspace.org
  211. Subject: Re: L0pht Security Advisory: Windows NT
  212.  
  213. Dildog <dildog@L0PHT.COM> writes:
  214. >                           L0pht Security Advisory
  215.  
  216. > ---
  217. > Workarounds/Fixes:
  218. > ---
  219. >
  220. >       I developed a patch for this security problem in the form of a
  221. > Win32 Service program that can be installed by the Administrator of the
  222. > system. It sets itself to run every time the system is started, and before
  223. > the user has the opportunity to start a program, it adjusts the
  224. > permissions of the DLL cache to something much safer.
  225.  
  226. Alternatively, you can set
  227. HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\ProtectionMode=1
  228. and reboot.
  229.  
  230.  
  231. Paul
  232.  
  233.  
  234.  
  235.  
  236.  
  237.